1) Technical Field
The present invention relates to a prediction method. It is particularly, but not exclusively, concerned with a method of prediction which uses computational fluid dynamics, and more particularly to a method of prediction of telemetry data from systems such as gas turbine engines.
A number of methods are used to extract data, such as temperatures, flows, windage, heat flux, and heat transfer coefficients, from computational fluid dynamics (CFD) analysis of engine test measurements. This data can then be used in conventional finite element (FE) analysis, for example to derive thermal boundary conditions for metal temperature predictions.
2) Related Art
Two existing approaches to the derivation of thermal boundary conditions in engine testing are discussed with reference to FIGS. 1 and 2.
The first approach, illustrated in the flow-chart of FIG. 1, generally involves solving the fluid dynamics of the problem and then interpreting the data to provide a conventional heat transfer coefficient and fluid temperature to enter into the existing metal temperature prediction code.
This approach suffers from a number of problems, in particular that the local fluid temperature which is used to extract the heat transfer coefficient is open to interpretation, or where it is back-calculated from a prior knowledge of the heat transfer coefficient, an unrepresentative value may be obtained. The derived heat transfer coefficients can also differ depending on the precise detail of how have been extracted. The heat transfer coefficients are also extracted from steady state CFD solutions where temperature gradients within the fluid and between the fluid and the bounding solid are small, which can lead to inaccuracies or even impossibilities in extracting sensible data, for example due to variations in fluid temperature, away from the solid surface, being of similar magnitude to the difference between the solid wall and chosen fluid temperature from the heat transfer extraction.
In order to address some of the above problems, a second approach has been considered which links the CFD and the metal temperature prediction codes directly and passes data from one to the other until a solution is achieved. This is illustrated in FIG. 2.
This approach removes the need for the CFD data to be interpreted before applying the metal temperature prediction program/code. However, the approach is extremely time consuming to implement since a CFD solution is required for each specific rotational speed the component is spinning at, and only once these have been generated can the linking and running of the CFD solutions and metal temperature prediction code be carried out. Generally for one set of temperature predictions (e.g. a single flight cycle) there are of the order of 25 speeds to be considered and thus 25 CFD solutions required. Each such solution takes approximately one week to produce. These solutions then need to be linked to the metal temperature prediction program and run for the flight cycle. It takes approximately 36 hours to run a single transient, so running all 25 transients would take several weeks. In the course of an engine project the models would have to be run several times to cope with the different cycles required. Thus this method is impractical except in a research environment.
It is noted that the above considerations relate to 2-dimensional CFD solutions, although there may be a demand in the future for 3-dimensional solutions, which would further increase the complexity and/or time for these calculations.